home
***
CD-ROM
|
disk
|
FTP
|
other
***
search
/
Columbia Kermit
/
kermit.zip
/
newsgroups
/
misc.19970326-19970626
/
000001_news@columbia.edu _Wed Mar 26 17:32:08 1997.msg
< prev
next >
Wrap
Internet Message Format
|
2020-01-01
|
5KB
Return-Path: <news@columbia.edu>
Received: from newsmaster.cc.columbia.edu (newsmaster.cc.columbia.edu [128.59.35.30])
by watsun.cc.columbia.edu (8.8.5/8.8.5) with ESMTP id RAA27699
for <kermit.misc@watsun.cc.columbia.edu>; Wed, 26 Mar 1997 17:32:07 -0500 (EST)
Received: (from news@localhost)
by newsmaster.cc.columbia.edu (8.8.5/8.8.5) id RAA12377
for kermit.misc@watsun; Wed, 26 Mar 1997 17:32:06 -0500 (EST)
Path: news.columbia.edu!not-for-mail
From: fdc@watsun.cc.columbia.edu (Frank da Cruz)
Newsgroups: comp.os.ms-windows.nt.misc,comp.protocols.kermit.misc
Subject: Re: K95 Kermit flickers on Key Input in NT4.0
Date: 26 Mar 1997 17:31:58 -0500
Organization: Columbia University
Lines: 84
Message-ID: <5hc84u$qum@watsun.cc.columbia.edu>
References: <5hbo8d$lbi$1@news.impulse.net>
NNTP-Posting-Host: watsun.cc.columbia.edu
Xref: news.columbia.edu comp.os.ms-windows.nt.misc:184911 comp.protocols.kermit.misc:6816
In article <5hbo8d$lbi$1@news.impulse.net>,
Stephen Au <stephen@arktel.com> wrote:
:
: I have been using K95 under WIN95 for sometime and it works OK (slow)
:
Slow compared to what?
: and I can't use just any window size I want.
:
Due to a bug in Windows 95.
: I recently upgraded my system to NT 4.0...
:
Which does not have the bug relating to console screen dimensions...
: and the first thing I noticed was that text in K95 window flickers as I
: was typing. This flickering happens even in the command screen, as well as
: when connected. I have not seen this problem on WIN95, and neither does
: this occur in vanilla DOS session in an NT window. I went over to a
: colleague's NT workstation and it does the same thing.
:
: The system I tried are PCI-based Pentium/120 and 133 (Dell). One with the
: STB PowerGraph Trio64V+ and the other one uses S3.
:
: K95 has patch 11 updates.
:
Which is current.
: Does anyone has similar problem and has a remedy? Thank you very much.
:
Some people have seen this, most do not see it.
: This is a big disappointment considering I have been using all versions
: of Kermit in MSDOS, Unix, and OS2, and these versions are rock solid.
:
In Windows, we're dealing with a much more... "complicated" environment.
There are infinite combinations of hardware, graphics adapters, drivers,
BIOS's, etc, and bugs in all of these.
Kermit is updating the screen in the approved Win32 manner. If there is
flicker, it is not caused by Kermit, but rather by the driver that Kermit
is calling upon to do it, and/or the video adapter.
The following entry from Kermit 95's BUGS.TXT file might be helpful:
27. Screen updates updates are slow on some PCs
Video drivers vary in speed. Those in Windows NT tend to be significantly
slower than those in Windows 95. Even in Windows 95, some drivers or
hardware might be slower than Kermit 95 was designed for. Kermit 95's
default screen-updating cycle is 100 milliseconds (1/10 second); if your
video driver is slower than that, you might be able to make Kermit go faster
by increasing (yes, increasing) its screen-update interval, for example:
SET TERMINAL SCREEN-UPDATE FAST 200
Flickering can occur when the video driver is not performing a comparison
between what is already on the screen and what it is being asked to write.
So it paints the entire window (which takes time) even when it doesn't have
to. When acceleration is on (and supported by the driver) minimal screen
paints occur and screen updates should be fast. In the Control Panel either
on the Display object or the System Object, there is a performance page which
allows you to set the Video Acceleration properties. Make sure this is set
to use full acceleration. The only flickering you should see in this case is
the mouse pointer, since it is turned off and on, before and after each
console screen paint.
If that doesn't help, you can experiment with Kermit 95's SET TERMINAL
SCREEN-UPDATE FAST and SMOOTH options to choose which algorithm is used to
update the screen when new data arrives from the host. Whenever a byte
arrives from the host it is processed by an incoming data thread. If it
results in a screen write, an internal screen buffer is updated and a "dirty"
flag is set. When using the FAST algorithm, the screen buffer is copied to
the physical screen on a timer thereby allowing the maximum data throughput
from the host to occur regardless of the speed of the video drivers. This is
the default. The negative aspect of this method is that on really fast
connections it is possible for some screen writes to never make it to the
screen, e.g. during continuous scrolling (but the data is processed correctly,
and can be viewed in the scrollback buffer). The SMOOTH option says to copy
the screen buffer to the window whenever the dirty flag is set. This results
in much slower data handling, and a potentially significant increase in the
number of screen writes.
- Frank